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1  Project  Goals  and  Chronology 

This  report  describes  our  research  on  advanced  scheduling  technologies  supported  by  the 
ARP  A/Rome  Lab  Planning  and  Decision  Aids  (PDA)  program  during  1997  -  2000.  At  the  outset, 
this  project  brought  together  Kestrel  Institute  and  Savi  Technology  to  develop  technology  for 
continuous  scheduling  based  on  highly-ac curate  real-time  asset  tracking  and  execution 
monitoring.  The  original  goal  was  to  demonstrate  the  benefits  of  combining  high-quality 
logistics  data  with  a  robust  scheduling  capability  in  an  operational  DoD  setting. 

Kestrel  brought  to  bear  its  software  synthesis  technology  which  allows  the  generation  of  correct- 
by-construction,  high-performance  schedulers  from  formal  specifications  of  the  problem  they  are 
intended  to  solve.  Savi  Technology,  Inc.  brought  to  bear  its  expertise  in  automatic  identification 
technology  and  asset  tracking  hardware  and  software  systems.  Savi  implemented  numerous 
government  and  commercial  asset  visibility  and  tracking  systems  employing  a  wide  range  of 
automatic  identification  technologies  (AIT),  including  bar-code,  optical  memory  cards,  smart 
cards,  portable  data  terminals,  and  radio  frequency  identification.  For  example,  Savi  provides 
high-quality  logistics  data  and  execution  monitoring  for  the  U.  S.  Army  and  U.  S.  TRANSCOM 
in  their  Ammunition  AIT  project.  We  hoped  to  demo  our  combined  results  in  this  context. 

Under  this  contract  Kestrel  and  Savi  codeveloped  a  continuous  scheduler  for  Yard  Management 
Systems,  based  on  data  from  the  Army's  Crane  Ammunition  Depot.  The  Yard  Management 
System  project  addresses  the  problem  of  scheduling  a  fleet  of  hostlers  (tractors)  in  a  dock-side 
depot.  A  typical  depot  has  various  types  of  temporary  storage  areas  where  cargo  is  held  for 
inspection  or  until  it  is  required  for  loading  onto  a  ship,  train  or  trailer  for  transportation  out  of 
the  depot.  The  hostlers  transfer  cargo  between  the  storage  areas  as  the  status  of  the  cargo  changes 
and  between  the  storage  areas  and  the  cranes  that  transfer  cargo  onto  or  off  ships  and  trains. 

This  demonstration  system,  while  successful,  didn't  fully  exploit  the  strengths  of  Kestrel's 
scheduling  technology.  One  goal  of  this  project  was  to  piggyback  on  some  of  Savi's  deployed 
systems  to  demonstrate  the  effectiveness  of  continuous  scheduling  in  a  context  where  Savi's 
realtime  tracking  technology  had  been  deployed.  As  it  happened,  Savi's  deployment  schedule  for 
its  Ammo  AIT  project  slipped,  depriving  the  project  of  its  main  application  domain.  After 
consultation  with  all  stakeholders.  Kestrel  and  Rome  Lab  decided  to  terminate  Savi's 
involvement  and  redirect  Kestrel's  research  effort  (in  December  1998). 

The  revised  project  had  two  directions: 

1.  Support  for  the  CAMPS  project  at  AMC  -  Together  with  BBN  and  Carnegie-Mellon 
University,  Kestrel  developed  an  advanced  scheduling  system  for  AMC  TACC  (Air 
Mobility  Command,  Tanker- Airlift  Operations  Center)  at  Scott  AFB.  This  system  is 
scheduled  for  integration  by  Logicon  Corporation  into  the  CAMPS  system  and 
deployed  in  2001. 

2.  Support  for  Planware  -  Planware  is  a  domain-specific  generator  of  high-performance 
scheduling  software.  The  goal  of  the  Planware  system  is  to  put  Kestrel's  scheduler 
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synthesis  technology  in  the  hands  of  users  who  aren't  specialists  in  formal  methods. 
Using  Planware,  the  user  interactively  specifies  a  problem  and  then  the  system 
automatically  generates  a  formal  specification  and  refines  it. 

Funding  problems  disrupted  this  project  in  1999.  The  Air  Force  terminated  6.3  funding  service¬ 
wide  in  GFY  2000,  leaving  this  project  unfinished.  Rome  Lab  was  able  to  find  some  additional 
funds  to  continue  Kestrel's  CAMPS  participation  until  May  2000.  At  that  point,  AMC  was  able 
to  pick  up  support  for  CAMPS  MPS. 


2  Overview 

This  report  describes  our  research  on  the  transformational  development  of  scheduling  soft-  ware. 
Our  approach  to  developing  scheduling  software  involves  several  stages.  The  first  step  is  to 
develop  a  formal  model  of  the  transportation  scheduling  domain,  called  a  domain  theory. 
Second,  the  constraints,  objectives,  and  preferences  of  a  particular  scheduling  problem  are  stated 
within  a  domain  theory  as  a  problem  specification.  Finally,  an  executable  scheduler  is  produced 
semi-automatically  by  applying  a  sequence  of  transformations  to  the  problem  specification.  The 
transformations  embody  programming  knowledge  about  algorithms,  data  structures,  program 
optimization  techniques,  etc.  The  result  of  the  transformation  process  is  executable  code  that  is 
consistent  with  the  given  problem  specification.  Furthermore,  the  resulting  code  can  be 
extremely  efficient. 

We  developed  this  transformational  technology  and  applied  it  to  several  application  areas.  First, 
we  focused  on  continuous  scheduling  to  sit  on  top  of  the  real-time  tracking  systems  supplied  by 
Savi.  Our  previous  schedulers  had  all  been  offline  batch  schedulers,  so  we  were  curious  to 
extend  our  generative  technology  to  cover  continuous  scheduling.  We  also  wanted  to  exploit  the 
availability  of  real-time  data  about  the  state  of  the  world  to  continuously  monitor  and  reschedule 
activities.  The  YMS  demonstration  system  described  in  Section  4  embodies  the  results  of  this 
effort.  Second,  we  used  our  transformation  system  KIDS  [7,  9]  to  generate  a  scheduler  for  one  of 
the  worlds  most  complex  scheduling  problems:  strategic  airlift  scheduling  at  the  Air  Mobility 
Command  at  Scott  AFB.  This  project  is  described  in  Section  5.  Finally,  we  focused  on 
incorporating  our  expertise  in  scheduler  generation  into  a  highly  automated  system  for  scheduler 
synthesis  (Planware),  which  is  described  in  Section  6. 


3  Project  Results 

This  section  provides  a  detailed  list  of  significant  accomplishments,  events,  demonstrations,  and 
systems  developed  under  this  project.  A  compact  summary  of  the  most  significant  achievements 
of  this  project  is  given  in  the  Concluding  Remarks  section. 

1.  YMS  demonstration  system  -  The  Yard  Management  System  project  addresses  the 
problem  of  scheduling  a  fleet  of  hostlers  (tractors)  in  a  dock-side  depot.  A  typical 
depot  has  various  types  of  temporary  storage  areas  where  cargo  is  held  for  inspection 
or  until  it  is  required  for  loading  onto  a  ship,  train  or  trailer  for  transportation  out  of 
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the  depot.  The  hostlers  transfer  eargo  between  the  storage  areas  as  the  status  of  the 
eargo  ehanges  and  between  the  storage  areas  and  the  eranes  that  transfer  eargo  onto  or 
off  ships  and  trains.  This  system  was  demonstrated  at  the  May  1998  and  Oetober  1998 
PDA  workshops. 

2.  Planware  -  A  working  version  of  Planware  was  developed  and  demonstrated 
extensively  at  workshops.  Among  the  key  developments  are 

(a)  Constraint  Acquisition  -  We  developed  a  new  tabular  format  for  aequiring 
seheduling  problem  requirements.  This  result  enabled  a  mueh  richer  means  for 
interactively  getting  user  input  on  the  scheduling  problem  at  hand,  without 
requiring  users  to  read  or  write  formal  specifications. 

(b)  Colimits  of  Diagrams  -  Another  key  technical  result  was  the  development  and 
implementation  of  colimits  of  diagrams,  which  enabled  us  to  provide  precise  sup¬ 
port  for  composing  structured  representations  of  knowledge.  We  believe  that  this 
result  is  a  major  mathematical  advance  with  respect  to  knowledge  representation 
and  processing,  far  transcending  our  particular  application  to  program  synthesis. 
We  use  colimits  of  diagrams  to  provide  better  support  for  design-by-classification, 
embodied  in  Planware's  substrate  called  Designware  (for  more  details,  see  [6,  5]). 
We  applied  for  a  patent  on  this  operation. 

(c)  Constraint  Propagation  Theory  -  We  developed  and  implemented  a  generalized 
theory  of  constraint  propagation  that  subsumes  earlier  forms  of  constraint 
propagation  (and-constraints)  and  global  search  (or-constraints). 

3.  CAMPS  Mission  Planning  System  (MPS)  -  We  developed  version  0.5  of  MPS  which 
was  released  at  the  end  of  the  project.  This  version  included  basic  scheduling  of 
aircraft  loading  and  routing,  aircrews,  and  mog  at  enroute  ports,  as  well  as  many  other 
features  required  for  deliberate  airlift  planning. 

4.  Publications 

Lee  Blaine,  Limei  Gilham,  Junbo  Liu,  Douglas  R.  Smith,  and  Stephen  Westfold, 
Planware  -  Domain-Specific  Synthesis  of  High-performance  Schedulers,  Proceedings 
of  the  Thirteenth  Automated  Software  Engineering  Conference,  IEEE  Computer 
Society  Press,  Eos  Alamitos,  California,  October,  1998,  270-280. 

Smith,  D.R.,  Mechanizing  the  Development  of  Software,  in  Calculational  System  De¬ 
sign,  Proceedings  of  the  NATO  Advanced  Study  Institute,  Eds.  M.  Broy  and  R.  Stein- 
brueggen,  lOS  Press,  Amsterdam,  1999,  251-292. 

Smith,  D.R.,  Designware:  Software  Development  by  Refinement,  invited  paper  in 
Proceedings  of  the  Eighth  International  Conference  on  Category  Theory  and 
Computer  Science,  Edinburgh,  September,  1999. 

Westfold,  S.J.  and  Smith,  D.R.,  Synthesis  of  Efficient  Constraint  Satisfaction  Pro- 
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grams,  Knowledge  Engineering  Reviews,  Speeial  Issue  on  AI  and  OR,  2001. 


5.  Patents  -  We  applied  for  a  patent  on  diagrams  of  eolimits: 

D.  Pavlovic,  J.  Liu,  and  D.R.  Smith,  Method  and  Apparatus  for  Determining  Colimits 
of  Hereditary  Diagrams,  patent  application  submitted  September  1999. 

6.  Project-related  Presentations,  Meetings  and  Events  -  Unless  otherwise  specified.  Dr. 
Smith  participated  in  each  item  below. 

■  CAMPS  meeting,  Scott  AFB,  20  May  97. 

■  ARPI  Annual  Workshop,  Lynnfield,  MA,  9-12  June  1997;  Dr.  Smith  received  the  Guns 
and  Butter  Award  from  the  DARPA  Program  Manager  for  “basic  research  and  a  solid 
record  of  successful  transitions  to  ARPI  customers”.  Dr  Smith  gave  an  invited  talk 
entitled  “Domain-Specific  System  for  Synthesizing  High-Performance  Schedulers";  Dr. 
Smith  gave  demos  of  Planware  and  KIDS;  Dr.  Smith  also  gave  a  talk  entitled  “Synthesis 
of  Real-Time  Schedulers". 

■  Interview  with  SAAM  and  Contingency  &  Exercise  mission  planners,  AMC  HQ,  Scott 
AFB,  29  September  97. 

■  CAMPS  meeting,  Logicon  HQ,  San  Pedro,  CA,  27-28  October  1997. 

■  PDA  Workshop,  San  Francisco,  4-6  Nov  97. 

■  CAMPS  meeting,  interview  with  SAAM  and  Contingency  &  Exercise  mission  planners, 
AMC  HQ,  Scott  AFB,  3  December  97. 

■  visited  MTMC  HQ,  Falls,  Church,  VA  to  discuss  Kl/Savi  scheduling  of  yard 
management  at  Sunny  Point.  Attending;  Col  Larry  Curtin,  Col  Morrow,  Dan  Monahan, 
16  January  1998. 

■  Talk  and  Demo  of  CAMPS  Mission  Planner,  Logicon  Office,  Scott  AFB,  28  January 
1998. 

■  Visited  Sunny  Point,  NC  to  interview  MOTSU  personnel,  17-18  Feb  98.  Result  was 
hostility  to  Kestrel/Savi  participation  in  an  application  effort,  so  we  looked  elsewhere. 

■  CAMPS  meeting.  Kestrel,  4  Mar  98 

■  CAMPS  meeting,  Logicon  HQ,  San  Pedro,  5  Mar  98 

■  CAMPS  demos  and  discussions,  Logicon  at  Scott  AFB,  28-29  Apr  98. 

■  DARPA  ISO  meeting,  Monterey,  CA,  4-5  May  98.  Presentation  of  the  Yard  Management 
System,  CAMPS,  and  Planware  at  ARPI  Annual  meeting,  Monterey,  CA,  6-7  May  1998. 

■  CAMPS  meeting,  Logicon  HQ,  San  Pedro,  19-20  May  98  (Tom  Emerson  attended) 

■  PDA  program  review  at  Kestrel  with  Al  Frantz,  25  Jun  98. 

■  Talks  on  Planware  and  category  theory  applied  to  software  refinement.  Air  Force  Rome 
Lab,  Rome,  NY,  2  Sept  98. 

■  Tutorial  on  Designware  and  paper  on  Planware,  Automated  Software  Engineering,  13-16 
Oct  98,  Honolulu,  HI. 

■  Talks  and  demos  on  Planware,  CAMPS,  and  Continuous  Scheduling  Architecture,  ARPI 
meeting,  Arlington  VA,  27-29  Oct  98. 

■  CAMPS  meeting,  AMC,  Scott  AFB,  17-19  Feb  99. 
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■  Project  review,  PDA,  John  Lemmer,  30  Apr  99 

■  Meeting  on  USAF  Common  Scheduler  Project,  ESC,  Hanscom  AFB,  Bedford,  MA,  21 
May  99. 

■  Invited  Talk,  \Software  Development  by  Mechanized  Refinement",  Workshop  on 
Language,  Logic,  and  Computation,  CSLI,  Stanford  University,  29  May  1999. 

■  Meeting  on  ESC  Common  Scheduler  Project,  at  Kestrel,  12  Aug  99.  Attending  were 
Frank  LaMonica  and  John  Lemmer  (AFRL),  Russ  Graves  (MITRE  &  ESC),  and  Kestrel 
personnel. 

■  Invited  Talk,  Designware,  Eighth  International  Conference  on  Category  Theory  and 
Computer  Science  (CTCS  99),  Univ.  Edinburgh,  UK,  10-12  September  1999. 

■  talk  on  Planware,  and  CAMPS  demo,  ARPI/PDA  Workshop,  Arlington  VA,  14-15 
September  1999. 

■  Invited  Talk,  CS  Colloquium,  Cornell  University,  30  Sept  99. 

■  Invited  talk  on  Designware,  High  Integrity  Systems  Conference,  Albuquerque,  NM,  14- 
17  Nov  99. 

■  Invited  talk  on  Planware,  to  Air  Force  Scientific  Advisory  Board,  AFRL,  Rome,  NY,  7-8 
Dec  99. 

■  CAMPS  meeting.  Kestrel,  13-14  April  2000. 

■  CAMPS  meeting,  Logicon  Scott  office,  O'Fallon,  IE,  11-12  May  2000. 

■  BBN,  Cambridge,  MA,  CAMPS  work,  2  Jun  00 

■  CAMPS  RAD/JAD,  alpha  release  of  CAMPS  MPS,  Logicon  Scott,  27-28  Jun  00 


4  Real-time  Tracking  and  Continuous  Scheduling 

The  Yard  Management  System  project  addresses  the  problem  of  scheduling  a  fleet  of  hostlers 
(tractors)  in  a  dock-side  depot.  A  typical  depot  has  various  types  of  temporary  storage  areas 
where  cargo  is  held  for  inspection  or  until  it  is  required  for  loading  onto  a  ship,  train  or  trailer  for 
transportation  out  of  the  depot.  The  hostlers  transfer  cargo  between  the  storage  areas  as  the  status 
of  the  cargo  changes  and  between  the  storage  areas  and  the  cranes  that  transfer  cargo  onto  or  off 
ships  and  trains. 

The  objective  in  scheduling  the  fleet  of  hostlers  is  to  reduce  the  loading  and  unloading  times  of 
ships  and  potentially  to  achieve  acceptable  loading  and  unloading  times  with  fewer  hostlers.  The 
main  difficulty  in  constructing  an  optimal  schedule  is  that  the  number  of  schedules  for  any  given 
set  of  cargo  movements  is  exponential  in  the  number  of  movements:  for  even  moderately  large 
numbers  of  movements,  it  is  infeasible  to  try  every  possible  schedule. 

One  solution  is  to  compute  lower  bounds  on  the  completion  time  for  schedules  and  use  this 
information  to  prune  from  the  schedule  search  space  schedules  that  could  not  possibly  be 
optimal.  The  lower  bound  computations  typically  require  much  less  time  than  would  the 
construction  of  the  schedules  themselves.  Furthermore,  a  given  lower  bound  computation 
typically  applies  to  a  large  number  of  schedules  (derived  from  a  common,  partially  constructed 
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schedule)  all  of  which  may  be  pruned.  Lower  bound  eomputations  can  thus  make  the 
construction  of  an  optimal  schedule  feasible. 


The  YMS  system 

We  developed  a  prototype  YMS  system  that  provides  continuous  scheduling  of  logistics 
operations  by  means  of  near-real  time  asset  visibility  data,  sentinels  and  monitoring  code, 
continuous  scheduling  engine,  and  an  execution  manager  (see  Figure  1). 

We  describe  the  various  components  of  this  architecture  below.  The  components  are  processes 
running  concurrently  on  a  Unix  workstation,  and  communicating  via  CORBA  middleware 
infrastructure. 

Savi  Asset  Manager 

The  Savi  Asset  Manager  provides  near-real  time  asset  data  acquisition  based  on  automatie 
identification  technologies.  The  asset  data  is  gathered  in  various  distributed  and  central  locations. 

Scheduling  Server 

The  scheduling  engine  transforms  the  available  resources,  delivery  requirements,  and  domain 
constraints  into  a  schedule  for  logistics  operations.  Several  rescheduling  algorithms  are  available 
-  global  reschedulers  for  times  when  it  is  more  important  to  reoptimize  the  schedule  than  to 
minimize  change,  and  loeal  reschedulers  when  minimizing  change  is  desirable.  We  anticipate 
supporting  user-specifiable  degrees  of  optimization  versus  change  in  the  scheduling  server.  The 
scheduling  engine  has  the  ability  to  determine  sensitive  events  or  combination  of  events  that 
could  require  rescheduling  operations.  Under  the  control  of  user-specified  parameters  and  other 
forms  of  guidance,  the  scheduling  server  automatically  generates  sentinels  to  watch  for  particular 
events. 

Execution  Manager 

The  execution  manager  provides  situation  visibility  and  control  to  the  user,  and  mediates  the 
activities  of  the  data  tracking  system  and  the  scheduling  server. 

Visibility  and  control:  The  status  of  the  assets  is  provided  via  direct  access  to  the  data  center.  The 
Schedule  viewer  provides  a  view  of  the  scheduled  logistics  operations,  for  a  record  of  recent 
changes  to  the  logistics  operations,  and  information  about  the  capabilities,  delivery  requirements, 
and  constraints.  The  Sentinel  Status  view  provides  information  of  currently  active  sentinels  and 
previously  triggered  sentinels.  The  user  specifies  which  sentinels  to  generate  and  how.  The  user 
can  also  choose  from  a  range  of  rescheduling  tools  and  tool  guidance  following  notification  of  a 
need  to  reschedule  from  a  sentinel. 
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Mediating  the  traeking  system  and  seheduler:  Sentinels  are  exeeuted  by  an  interpreter  in  the 
exeeution  engine  that  ereates  a  proeess  that  watehes  (aetive  sentinel)  for  a  given  set  of  events. 
The  sentinel  remains  aetive  until  the  events  happen  or  the  sentinel  is  eaneeled  or  replaeed.  If  a 
sentinel  event  oeeurs,  the  exeeution  manager  notifies  the  user  and  may  trigger  the  replanning 
operation. 

Kestrel  researehers  eonstrueted  a  domain  theory  for  the  YMS  seheduler  that  models  the  typieal 
operation  of  a  depot  and  eontaining  algebraie  laws  that  permit  the  automated  derivation  of  lower 
bound  funetions  suited  to  the  depot  (See  Appendix  A).  Furthermore,  the  domain  theory  eontains 
laws  that  permit  the  automated  instantiation  of  various  algorithm  theories  sueh  as  global  seareh, 
loeal  seareh  and  greedy  heuristie  algorithms.  Instantiation  of  these  theories  would  produee  a 
family  of  sehedulers  having  various  degrees  of  eompromise  between  seheduler  exeeution  time 
and  the  quality  of  the  sehedules  produeed  (not  all  of  the  sehedulers  will  produee  optimal 
sehedules).  The  family  of  sehedulers  would  also  eontain  real-time  resehedulers  whieh  use 
information  provided  by  real  time  traeking  systems  to  adjust  sehedules  as  they  are  exeeuted  to 
aeeount  for  deviations  between  predieted  and  aetual  performanee. 

Sueeessful  demonstrations  of  the  YMS  system  were  given  at  the  ARPI  workshops  in  May  1998 
and  Oetober  1998. 


5  CAMPS  Mission  Pianning  System 

This  seetion  provides  a  brief  overview  of  the  algorithm  underlying  the  Mission  Planner  in 
CAMPS.  The  MPS  algorithm  operates  on  level  2  TPFDD  data  and  generates  mission  plans  over 
nominal  aireraft  and  erews.  The  MPS  traeks  and  eonstrains  the  following  kinds  of  resourees  in 
eonstrueting  a  mission  plan:  (1)  aireraft,  (2)  erews  and  their  duty  days,  (3)  parking  mog,  (4) 
working  mog,  (5)  runways  (takeoff  and  landing  separations),  (6)  port  operating  hours.  Currently, 
fuel  supplies  at  ports  are  traeked  but  not  eonstrained. 

The  MPS  algorithm  essentially  iterates  over  movement  requirements  whieh  are  sorted  by 
inereasing  LAD  primarily. 

1 .  The  main  control  loop: 

For  eaeh  movement  requirement  (MVR),  the  algorithm  attempts  to  move  it  in  the 
eontext  of  previously  planned  missions.  First,  the  algorithm  tries  to  plaee  the  MVR  on 
existing  mission  provided  that  (1)  it  has  eapaeity,  (2)  the  mission  route  ineludes  the 
POE  and  POD,  (3)  the  mission  is  feasible  with  respeet  to  the  ALD,  EAD  and  EAD  of 
the  MVR.  If  an  existing  mission  eannot  (fully)  earry  the  MVR,  then  the  algorithm  will 
attempt  to  ereate  a  new  mission. 

2.  Creating  a  new  mission: 

Given  MVR,  we  first  look  ahead  in  the  list  of  unseheduled  movement  requirements  to 
find  those  that  eould  be  eoalleseed  with  it;  in  partieular,  we  look  for  requirements  from 
the  same  (or  a  nearby)  POE  with  a  similar  ALD  that  are  going  to  the  same  POD.  If 
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enough  cargo  (or  PAX)  can  be  found  to  justify  a  new  mission  (according  to  a 
minimum  threshold  per  MDS),  then  a  route  generator  is  called  to  produce  a  candidate 
list  of  available  aircraft  and  routes.  Route  generation  includes  positioning  from  the 
current  location  of  the  aircraft  to  the  POE,  travel  through  enroutes  (including  possible 
AR  stops)  to  the  POD,  followed  optionally  by  depositioning  to  a  recovery  base.  For 
each  leg  of  the  mission,  the  algorithm  generates  choices  of  (1)  crew  and  whether  the 
crew  flies  the  leg  in  their  current  duty  or  the  next,  (2)  base  open  hours  interval  for 
departure,  (3)  takeoff  position  (to  enforce  takeoff  separations),  (3)  base  open  hours 
interval  for  arrival,  and  (4)  landing  position  (to  enforce  landing  separations).  If  mog 
bounds  are  specified  for  ports  along  the  route,  then  parking  mog  and  working  mog  are 
tracked  and  the  constraints  are  enforced. 

The  Mission  Planner  is  based  on  constraint  propagation  technology.  See  [9]  for  more  details 
about  the  nature  and  design  of  constraint-based  algorithms  for  scheduling.  One  key  feature  of  our 
approach  is  to  use  time  windows  for  every  temporal  decision;  in  particular  during  scheduling,  the 
departure  time  of  every  flight  is  given  by  a  time  window  -  an  earliest  departure  time  and  a  latest 
departure  time.  When  the  departure  times  of  flights  must  be  coordinated,  for  example,  by 
enforcement  of  a  minimum  separation  between  takeoffs  at  a  port,  then  a  dependence  constraint  is 
asserted  between  flights  so  that  the  earliest  departure  time  of  one  flight  is,  say,  at  least  15 
minutes  before  the  earliest  departure  time  of  another  flight  departing  from  the  same  station.  If  the 
departure  time  of  the  first  flight  must  be  delayed,  then  the  asserted  constraint  will  cause  the 
earliest  departure  time  of  the  second  flight  to  be  delayed  if  necessary  to  enforce  the  minimum 
takeoff  separation.  In  this  scenario  a  change  to  the  time  window  of  one  flight  is  propagated 
through  the  takeoff  separation  constraint  to  cause  a  change  to  the  time  window  of  the  second 
flight  -  an  example  of  constraint  propagation. 


6  Planware 

This  section  presents  an  overview  of  Planware,  a  generator  of  high-performance  scheduling 
algorithms,  currently  being  developed  at  Kestrel  Institute.  Our  aim  is  to  convey  a  sense  of  the 
rationale  for  Planware,  the  design  process  that  it  supports,  the  architecture  of  the  current 
Planware  system,  and  our  results  to  date.  The  reader  may  find  more  detail  in  the  references. 

Architecturally,  Planware  is  an  extension  of  the  Specware  system  [10],  a  system  for  developing 
formal  specifications  and  refinements  based  on  concepts  from  higher-order  logic  and  category 
theory.  Planware  and  Specware  embody  theoretical  developments  stemming  from  Kestrel's 
experience  with  previous  systems,  such  as  KIDS  [7]  and  DTRE  [2]. 

The  goal  of  Planware  is  to  allow  experts  in  planning  and  scheduling  to  assemble  quickly  a 
specification  of  a  scheduling  problem,  and  to  generate  automatically  a  high-performance 
scheduler  from  it.  The  user's  interactions  with  the  system  are  designed  to  be  entirely  in  the 
scheduling  domain  {  the  user  does  not  need  to  read  or  write  formal  specifications,  nor  to 
understand  the  logical  and  category-theoretic  foundations  of  the  system.  We  have  invested 
substantial  effort  in  automating  the  construction  of  scheduling  domain  theories. 
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Figure  2:  Taxonomy  of  Resource  Theories 

To  assemble  a  requirement  specification  and  underlying  domain  theory,  Planware  requires 
very  little  information  from  the  user: 

1 .  to  select  from  a  taxonomy  of  resource  theories  the  particular  kind  of  resource  against 
which  to  schedule  the  tasks  (See  Figure  2) 

2.  to  modify  a  spreadsheet-like  table  of  expressions  that  provide  bounds  on  the  various 
attributes  of  reservations  of  the  selected  resources  (See  Figure  3). 

From  this  minimal  amount  of  information,  Planware  can  automatically 

■  generate  a  formal  specification  of  the  scheduling  problem  (plus  the  relevant  background 
concepts  that  comprise  a  domain  theory), 

■  reformulate  the  specification  using  datatype  refinements  to  build  some  of  the  problem 
constraints  directly  into  the  schedule  datatype,  allowing  a  dramatic  simplification  of  the 
specification, 

■  apply  domain-independent  knowledge  about  designing  global  search  (backtracking) 
algorithms  with  constraint  propagation, 

■  apply  datatype  refinements  and  optimization  techniques,  and  finally 

■  generate  Common  Lisp  code. 
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Figure  3:  Spreadsheet-like  Interface  for  Acquiring  Scheduling  Constraints 

For  example,  after  design  and  refinement,  the  speeifieation  of  a  transportation  seheduling  domain 
eomprises  about  10,000  lines  of  text  of  whieh  about  3000  lines  are  the  seheduling  algorithm  (the 
remainder  eonsists  of  axioms  and  datatype  operations  that  are  not  needed  by  the  running 
seheduler). 

A  key  point  here  is  that  the  high  level  of  automation  in  Planware  is  aehieved  by  applying 
domain-  speeifie  eontrol  (via  a  hand-built  taetie): 

1 .  to  eonstruet  a  problem  speeifieation  and  domain  theory, 

2.  to  apply  a  series  of  domain-independent  design  theories  and  eode -generation  rules.  The 
result  is  a  fast,  eorreet,  executable  scheduler  automatically  constructed  from  the  user's 
description  of  a  scheduling  problem. 

We  believe  that  Planware  is  a  new  paradigm  for  domain-specific  software  generators.  Planware 
differs  from  other  domain-specific  software  generators  in  that  it  is  built  on  a  foundation  of 
domain-independent  general-purpose  software  specification  and  synthesis  capabilities 
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(Specware/Designware).  In  particular,  Planware  relies  on 

1.  the  Speeware  eapabilities  for  eomposing  speeifieations,  refining  them  and  translating 
to  eode  (espeeially  eolimits  of  diagrams); 

2.  the  Designware  libraries  of  domain-independent  design  knowledge  about  algorithms, 
datatype  refinements,  and  expression  optimization  teehniques  (and  their  applieation 
taetics)  to  eonstruet  refinements. 

The  domain-speeifieity  of  Planware  eomes  in  the  form  of 

specifications  of  domain  knowledge  -  the  abstract  scheduling  speeifieation,  the  taxonomies  of 
task  and  resouree  theories,  ete. 

scheduling  spec  construction  tactics  -  tactics  for  lifting  properties  of  tasks  to  eonstraints  on  the 
seheduler,  taeties  for  lifting  resouree  eonstraints  to  scheduling  eonstraints,  tactics  for 
constructing  the  eonstruetors  and  other  datatype  operations  needed  by  the  refined  Task, 
Resouree,  Reservation,  and  Sehedule  spees, 

embeded  algorithm  design  tactic  -  tactics  for  generating  a  global  search  theory  for  the 
scheduling  problem  at  hand,  etc. 

The  background  of  domain-independent  design  knowledge  allows  a  user  to  derive  software  even 
when  the  requirements  fall  outside  the  domain-specific  scope  of  the  system.  The  user  then  gets 
less  automation,  and  must  supply  more  guidance  in  the  construction  process. 

There  are  many  things  to  be  done  before  Planware  can  be  deployed.  One  crucial  extension  is 
allowing  the  user  more  flexibility  in  supplying  task  information.  We  are  developing  a 
spreadsheet-like  interface  that  is  derived  from  the  user's  choice  of  resource  theory  and  presents 
the  user  with  plausible  options  for  lower/exact/upper  bounds  on  all  crucial  attributes  of  a 
reservation  for  that  kind  of  resource.  We  are  working  to  let  the  user  choose  and  modify  arbitrary 
entries.  As  before  the  user  only  interacts  with  the  system  in  domain-specific  terms.  Another  vital 
extension  is  to  generalize  the  abstract  scheduling  spec  to  multiple  resource  classes.  Another 
extension  that  is  underway  is  to  extend  Planware  to  allow  the  synthesis  of  scheduling  systems, 
including  visual  displays,  editors,  GUI,  database  mediators,  and  so  on. 

See  [1]  for  more  details  and  an  example  of  Planware  in  action. 


7  Concluding  remarks 

This  project  enabled  us  to  show  the  flexibility  of  our  specs-to-code  technology  as  applied  to  a 
range  of  scheduling  problem  types:  continuous  scheduling,  large-scale  complex  airlift 
scheduling,  and  highly-automatic  scheduler  generators.  We  expect  each  of  these  areas  to 
continue  to  develop  and  to  result  in  improved  products  for  DoD  needs. 
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Summing  up,  this  project  has  led  to  theoretical  breakthroughs,  direct  application  support  for  the 
US  Air  Force,  and  business  opportunities  in  technology  transfer: 


1.  Fundamental  Breakthroughs  in  Software  Synthesis  Technology  - 

■  Diagram  Colimit  -  This  is  a  fundamental  tool  for  automatically  composing  knowledge 
structures.  Our  belief  in  the  long-term  criticality  of  this  operation  is  reflected  in  our 
applying  for  a  patent  on  it. 

■  Planware  -  Planware  is  a  new  paradigm  for  domain-specific  software  generators. 
Planware  differs  from  other  domain-specific  software  generators  in  that  it  is  built  on  a 
foundation  of  domain-independent  general-purpose  software  specification  and 
synthesis  capabilities  (e.g.  the  diagram  colimit  operation  in  Specware/Designware). 
Our  discovery  of  the  tabular  spreadsheet-like  format  for  acquiring  problem 
requirements  was  a  significant  breakthrough  in  the  Planware  interface.  It  is 
paradigmatic  of  how  a  simple  domain-specific  specification  interface  can  be  built  on 
the  basis  of  a  clear  mathematical  model  of  a  class  of  problems. 

2.  Application  Support  for  the  US  Air  Force  -  CAMPS  MPS  is  the  next-generation  scheduling 
system  at  the  TACC  at  AMC,  Scott  AFB.  It  provides  speed  and  scheduling  capabilities  far 
beyond  AMC's  current  tools.  MPS'  support  for  hub-and-spoke  operations  may  enable  a  radical 
change  in  AMC  airlift  operations  strategy. 

3.  Tech  Transfer  and  Business  Opportunities  -  Planware  as  a  generator  (vending  machine)  of 
schedulers  has  generated  commercial  interest.  Kestrel  Technology  (a  for-profit  LLC  started 
recently  to  develop  and  transfer  Kestrel  Institute  technologies)  has  won  an  SBIR  to  develop 
Planware  into  a  commercially  viable  tool.  We  also  anticipate  that  Kestrel  Technology  will 
provide  long-term  maintenance  support  to  AMC  for  CAMPS  MPS,  and  will  be  looking  for 
other  opportunities  for  developing  variants  of  MPS  for  the  US  Air  Force. 
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Appendix  A  Theories 


A  VMS  Theories 

This  appendix  details  the  KIDS  theories  for  the  Yard  Management  System  scheduler.  A  brief 
summary  of  the  theories  is  presented  below,  followed  by  the  full  text  of  the  theories. 

Cargo  A  simple  ADT  representing  a  cargo  item. 

Slot  The  various  types  of  storage  area  in  a  yard  (bunkers,  loading  bays,  etc.)  are  uniformly 
represented  as  'slots'. 

Movement  Request  This  ADT  represents  a  task  for  the  hostlers  in  the  form  of  an  item  of 
cargo  to  be  moved  from  a  source  slot  to  a  destination  slot.  Some  additional  information, 
such  as  the  distance  between  source  and  destination  fields  is  cached  for  efficiency  in 
computing  metrics  on  schedules. 

Ship  Manifest  This  represents  a  partial  order  on  movement  requests  that  arises  from 
physical  restrictions  on  loading  and  unloading  ships.  The  movement  requests  are 
categorized  into  numbered  strata  such  that  all  movement  requests  in  a  given  strata  must 
be  accomplished  before  any  movement  requests  from  higher-numbered  strata,  but  there 
is  no  ordering  on  the  movement  requests  within  a  single  strata. 

Geometry  The  geometry  of  a  yard  is  represented  essentially  as  a  graph  of  distances 
between  slots.  The  graph  is  directed  to  allow  for  asymmetric  routes  (e.g.,  one-way 
roads). 

Hostler  The  Hostler  theory  defines  an  ADT  to  represent  individual  hostlers  and  their 
properties;  e.g.,  their  speed  and  turn-around  times. 

Yard  A  Yard  represents  a  single  physical  scheduling  site:  its  geometry  (slots  and  the 
distances  between  them)  and  resources  (hostlers). 

Reservation  A  reservation  represents  the  assignment  of  a  hostler  to  satisfy  a  particular 
movement  request  during  a  particular  time  period. 

Schedule  A  schedule  represents  the  assignments  of  all  hostlers  over  a  certain  time  period. 
Conceptually,  a  schedule  is  a  set  of  reservations. 

Work  Metric  The  work  metric  is  used  to  assess  schedules  both  in  gauging  the  quality  of  a 
schedule  and  in  computing  lower  bounds  on  completions  of  partial  schedules  (these 
lower  bound  are  used  for  pruning  searches).  The  work  represented  in  a  schedule  in 
based  on  productive  work  (cargo  moved)  and  unproductive  work  (repositioning  of 
hostlers  between  cargo  movements). 
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YMS  Theory  This  theory  defines  feasibility  on  hostler  sehedules.  The  primary 
components  of  feasibility  are:  the  ordering  on  cargo  movements  is  respected;  each 
reservation  is  long  enough  for  its  cargo  movement  to  be  accomplished;  successive  pairs 
of  reservations  for  a  given  hostler  are  sufficiently  separated  to  allow  for  repositioning  of 
the  hostler;  the  schedule  does  not  allocate  more  hostlers  than  are  available  in  the  yard. 

Global  Search  with  Pruning  This  theory  defines  an  algorithm  schema  for  performing 
global  search  with  pruning  based  on  a  lower  bound  on  the  costs  of  all  schedules  in  a 
given  branch  of  the  search  space.  The  schema  includes  a  parameter  that  allows  the 
quality  of  the  final  schedule  to  be  specified  in  terms  of  deviation  from  true  optimality 
(e.g.,  'within  5%  of  optimal').  Reducing  the  quality  even  slightly  from  strict  optimality 
can  dramatically  reduce  the  size  of  the  search  space.  The  theory  also  shows  how  the 
search  can  be  initialized  with  a  schedule  generated  by  a  quick  but  non-optimizing 
heuristic  scheduler  to  further  reduce  the  size  of  the  search  space. 

Greedy  Append  for  Earliest  Finish  This  theory  is  an  example  of  a  greedy  heuristic 
scheduler  that  can  be  used  to  initialize  the  pruning  global  search  scheduler,  ft  is  based 
on  constructing  reservations  to  minimize  the  finishing  time  for  some  movement  request 
chosen  at  random  from  the  head  of  the  manifest  (such  that  the  ordering  of  the 
movement  requests  is  respected). 


A.l  Cargo 


!!  in-package("RE") 

!!  in-gtarnniait'THEDRY-GRAMMAR,  'cypress-grammar) 
%  Represents  an  item  of  ear  go. 

THEORY  CARGO 


% - 

THEORY-IMPORTS  {} 


% - 

THEORY-TYPE-PARAMETERS  {} 


%  - 

THEORY-TYPES 

type  eargo-id  =  symbol 
type  eargo-type  =  symbol 
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type  cargo  =  tuple(id;  cargo-id,  cargo-type:  cargo-type) 


% - 

THEORY-OPERATIONS 

function  cg-make(id;  cargo-id,  cargo-type:  cargo-type):  cargo 
=  <  id,  cargo-type  > 

function  cg-id(c:  cargo):  cargo-id 
=  c.id 

function  cg-type(c:  cargo):  cargo-type 
=  c.cargo-type 

END-THEORY 


A.2  Slot 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 

%  Represents  a  "slot"  (hostler  berth)  in  a  yard. 

THEORY  SLOT 

% - 

THEORY-TYPES 

type  slot-id  =  fixnum 

type  slot-name  =  symbol 

type  slot  =  tuple(id:  slot-id,  name:  slot-name) 


% - 

THEORY-OPERATIONS 

function  sl-make(id:  slot-id,  name:  slot-name):  slot 
=  <id,  name> 

function  sl-id(s:  slot):  slot-id 
=  s.id 

function  sl-name(s:  slot):  slot-name 
=  s.name 
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END-THEORY 


A.3  Movement  Request 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 
%  Represents  a  request  to  move  eargo. 

THEORY  MOVEMENT-REQUEST 


% - 

THEORY-IMPORTS  (SLOT,  CARGO,  GEOMETRY} 

% - 

THEORY-TYPES 

type  mvr  =  tuple(souree;  slot-id, 

destination;  slot-id. 


eargo:  eargo, 
tag:  fixnum, 
dist:  distanee, 
load;  fixnum) 


% - 

THEORY-OPERATIONS 

funetion  mvr-make(s:  slot-id,  d;  slot-id,  e:  eargo):  mvr 
=  <s,  d,  e,  undefined,  undefined,  undefined  > 

funetion  mvr-souree(m:  mvr):  slot-id 
=  m.souree 

funetion  mvr-destination(m:  mvr):  slot-id 
=  m.  destination 

funetion  mvr-eargo(m:  mvr):  eargo 
=  m.  eargo 
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function  mvr-set-tag(m;  mvr,  tag:  fixnum):  mvr 
=  <mvr-source(m), 

mvr-destination(m) , 

mvr-cargo(m), 

tag, 

m.dist, 

m.load> 

function  mvr-tag(m:  mvr):  fixnum 
=  m.tag 

function  mvr-compute-distance(m:  mvr,  g:  geo):  mvr 
=  let(s:  slot-id  =  mvr-source(m), 

d:  slot-id  =  mvr-destination(m)) 

let(dist:  distance  =  geo-distanee(g,  s,  d)) 

<s,  d,  mvr-eargo(m),  mvr-tag(m), 
dist, 

(dist  div  *LOADED-HOSTLER-SPEED*  -f  *TRIP-DURATION-OVERHEAD*)  > 

funetion  mvr-distanee(m:  mvr,  g:  geo):  distanee 
=  if  defined? (m.dist) 
then  m.dist 

else  geo-distanee(g,  mvr-souree(m),  mvr-destination(m)) 

funetion  mvr-eaehed-distanee(m:  mvr):  distanee 
=  m.dist 

funetion  mvr-load(m:  mvr):  fixnum 
=  m.load 


% - 

THEORY-LAWS 

assert  mvr-souree-and-destination-different 
fa(mvr)  mvr-souree(mvr)  ~  =  mvr-destination(mvr) 

END-THEORY 

A.4  Ship  Manifest 


!!  in-paekage("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'eypress-grammar) 
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THEORY  SHIP-MANIFEST 


% - 

THEORY-IMPORTS  {TIME-AND-DISTANCE,  MOVEMENT-REQUEST} 

% - 

THEORY-TYPE-PARAMETERS  {} 


% - 

THEORY-TYPES 
type  rank  =  fixnum 

type  repo-map  =  tuple(index:  seq( fixnum), 

distanees:  seq(distanee)) 
type  manifest  =  tuple(rank;  fixnum, 

loaded:  set(mvr), 
unloaded:  set(mvr), 
unloaded-distanee:  distanee, 
repo:  repo-map 
) 


% - 

THEORY-OPERATIONS 

funetion  man-make-empty():  manifest 
=  <0,  {},{},  0,  undefined > 

funetion  man-rank(man:  manifest):  fixnum 
=  man.  rank 

funetion  man-add-stratum(man:  manifest,  mvrs:  set(mvr)):  manifest 
=  let(rank  =  man-rank(man)-l-l) 

<rank, 
man.  loaded, 

(man. unloaded  union 

image(lambda(m:  mvr)  mvr-set-tag(m,  rank),  mvrs)), 
undefined, 
undefined  > 

funetion  man-loaded(man:  manifest):  set(mvr) 

=  man.  loaded 
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function  man-unloaded(man:  manifest):  set(mvr) 

=  man.  unloaded 

funetion  man- finished? (man:  manifest):  boolean 
=  man-unloaded(man)  =  {} 

funetion  man-rank-of-mvr(man:  manifest,  m:  mvr):  fixnum 
=  mvr-tag(m) 

funetion  man-mvr-less?(man:  manifest,  mvrl:  mvr,  mvr2:  mvr):  boolean 
=  mvr-tag(mvrl)  <  mvr-tag(mvr2) 

funetion  man-mvr-has-been-loaded? (man:  manifest,  mvr:  mvr):  boolean 
=  mvr  in  man-loaded(man) 

funetion  man-remove-mvr-from-distanee-map(man:  manifest,  done:  mvr) 
:  repo-map 

=  if  not(defined?  (man.  repo)) 
then  undefined 
else  <  man. repo. index, 

seq-shadowl (man. repo. distanees,  mvr-tag(done),  0)> 

funetion  man-mark-mvr-loaded( 
man:  manifest,  mvr:  mvr  |  mvr  in  man-unloaded(man) 

):  manifest 
=  (<  man.  rank, 

(man. loaded  with!  mvr), 

(man. unloaded  less!  mvr), 

(man.unloaded-distanee  -  mvr-load(mvr)), 
man-remove-mvr-from-distanee-map(man,  mvr)  > ) 

funetion  man-head(man:  manifest):  set(mvr) 

=  let(min-rank:  fixnum 

=  min-i(image(lambda(m:mvr)  man-rank-of-mvr(man,  m), 
man-unloaded(man)))) 

filter(lambda(m:  mvr)  man-rank-of-mvr(man,  m)  =  min-rank, 
man-unloaded(man)) 

funetion  man-tail(man:  manifest):  set(mvr) 

=  let(min-rank:  fixnum 

=  min-i(image(lambda(m:mvr)  man-rank-of-mvr(man,  m), 
man-unloaded(man)))) 

filter(lambda(m:  mvr)  man-rank-of-mvr(man,  m)  >  min-rank, 
man-unloaded(man)) 
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function  man-refined? (man  1:  manifest,  man2;  manifest):  boolean 

funetion  man-eompute-unloaded-distanee(man;  manifest,  g:  geo) 

;  manifest 

=  let(new-unloaded;  set(mvr)  = 

image(lambda(m:  mvr)  mvr-eompute-distanee(m,  g),  man-unloaded(man))) 
let(dist;  distanee  = 

reduee(-l-,  image(mvr-load,  set-to-seq(new-unloaded)))) 

<  man. rank,  man. loaded,  new-unloaded,  dist,  man. repo  > 

funetion  man-unloaded-distanee(man;  manifest):  distanee 
=  man.unloaded-distanee 

funetion  man-mvrs-in-order(man:  manifest):  seq(mvr) 

=  if  man-finished?(man) 
then  [] 
else 

let(m:  mvr  =  arb(man-head(man))) 

prepend(man-mvrs-in-order(man-mark-mvr-loaded(man,  m)),  m) 

funetion  man-find-elosest-mvr(m:  mvr,  s:  seq(mvr),  i:  fixnum,  g:  geo) 

:  tuple(mvr,  distanee,  mvr) 

=  if  i=size(s) 
then  <m,  0,  undefined  > 
elseif  i=size(s)  -  1 
then  <m, 

geo-distanee(g,  mvr-destination(m),  mvr-souree(last(s))), 
last(s)  > 

else 

let(md:  tuple(mvr,  distanee,  mvr) 

=  reduee(lambda(x:  tuple(mvr,  distanee,  mvr), 
y:  tuple(mvr,  distanee,  mvr)) 
if  X.2  <  =y.2  then  x  else  y, 
image(lambda(j) 

<m, 

geo-distanee(g,  mvr-destination(m),  mvr-souree(s(j))), 

s(j)>. 

[i+1  ..  size(s)]))) 
md 

funetion  man-find-elosest-mvrs-aux(todo:  seq(mvr),  g:  geo, 
done:  seq(mvr),  ehosen:  map(mvr,  set(mvr)), 
elosests:  seq(tuple(mvr,  distanee,  mvr)) 

):  seq(tuple(mvr,  distanee,  mvr)) 

=  if  empty(todo) 
then  elosests 


22 


else 

let(next:  mvr  =  first(todo)) 
let(eandidates:  seq(tuple(distanee,  mvr)) 

=  [  <d,m>  I  (m:  mvr,  d:  distanee) 
m  in  done 

&  (m  in  domain(ehosen) 

=  >  fa(e;  mvr)(e  in  ehosen(m) 

=  >  mvr-destination(e)  ~  =  mvr-destination(next))) 

&  d  =  geo-distanee(g,  mvr-destination(next),  mvr-souree(m))  ]) 
let(de;  tuple(distanee,  mvr) 

=  reduee(lambda(dml :  tuple(distanee,  mvr), 

dm2;  tuple(distanee,  mvr)) 
if  dml.  1  <  =dm2. 1  then  dml  else  dm2, 
eandidates)) 

let(ehoiee:  mvr  =  de.2, 
dist:  distanee  =  de.l) 

man-find-elosest-mvrs-aux( 

rest(todo), 

g, 

append(done,  next), 
ehosen 

+  *  { I  ehoiee  -  >  if  defined? (ehosen(ehoiee)) 
then  ehosen(ehoiee)  with  next 
else  {next}  | } , 

prepend(elosests,  <next,  dist,  ehoiee  >)) 

funetion  man-fmd-elosest-mvrs(mvrs:  seq(mvr),  g:  geo) 

:  seq(tuple(mvr,  distanee,  mvr)) 

=  let(rev:  seq(mvr)  =  reverse(mvrs)) 
let(m;  mvr  =  first(rev)) 
let(e  =  <m,  0,  undefined  >) 

man-find-elosest-mvrs-aux(rest(rev),  g,  [m],  {|  |},  [e]) 

funetion  man-eompute-elosest-sourees(man:  manifest,  g:  geo):  manifest 
=  let(mvrs:  seq(mvr)  =  man-mvrs-in-order(man)) 
let(elosest:  seq(tuple(mvr,  distanee,  mvr)) 

=  man-find-elosest-mvrs(mvrs,  g)) 

let(sorted:  seq(tuple(mvr,  distanee,  mvr)) 

=  sort(eopy-list(elosest), 

lambda(x:  tuple(mvr,  distanee,  mvr),  y:  tuple(mvr,  distanee,  mvr)) 
x.2>  =y.2)) 
let(index:  seq(fixnum) 

=  image(lambda(x:  tuple(mvr,  distanee,  mvr))  mvr-tag(x.  1),  sorted)) 
let(distanees:  seq( distanee) 

=  image(lambda(x:  tuple(mvr,  distanee,  mvr))  x.2,  elosest)) 

(< man. rank,  man. loaded,  man. unloaded,  man.unloaded-distanee. 
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<  index,  distances  >  >) 

function  smaller-i(x:  fixnum,  y:  fixnum):  fixnum 
=  if  X  <  y  then  x  else  y 

function  sum-n-non-zeros(s:  seq( distance),  index:  seq(fixnum), 
n:  fixnum,  pos:  fixnum,  total:  distance 
):  distance 

=  if  pos  >  size(index)  or  n=0 
then  total 

elseif  s(index(pos))  =  0 

then  sum-n-non-zeros(s, index,  n,  pos  +  1,  total) 

else  sum-n-non-zeros(s,  index,  n  -  1,  pos  +  1,  total +s(index(pos))) 

function  man-repositioning-lower-bound(man:  manifest,  Y :  yard) 

:  distance 

=  reduce(  +  ,  man. repo. distances,  0) 

-  sum-n-non-zeros(man. repo. distances,  man. repo. index, 
smaller-i(size(y-hostler-ids(Y))  -  1, 

size(man .  repo .  index)) , 

1,0) 


% - 

THEORY-LAWS 

assert  man-head-and-tail-disjoint 
fa(m)  man-head(m)  intersect  man-tail(m)  =  {} 

assert  man-head-and-tail-cover-unloaded 
fa(m)  man-head(m)  union  man-tail(m)  =  man-unloaded(m) 

assert  man-equivalence-of-loaded-and-mvr-has-been-loaded 
fa(m)  man-loaded(m) 

=  {  mvr  I  (mvr)  man-mvr-has-been-loaded?(m,  mvr)  } 

assert  man-loaded-and-unloaded-are-disjoint 
fa(m)  man-loaded(m)  intersect  man-unloaded(m)  =  {} 

assert  man-mvrs-in-head-are-not-pre-ordered- 1 
fa(m,  mvrl,  mvr2) 

mvrl  in  man-head(m)  &  mvr2  in  man-head(m) 

=  >  man-mvr-less?(m,  mvrl,  mvr2)  =  false 

assert  man-mvrs-in-head-are-not-pre-ordered-2 
fa(m,  mvrl,  mvr2) 
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mvrl  in  man-head(m)  &  mvr2  in  man-head(m) 

=  >  man-mvr-less?(m,  mvr2,  mvrl)  =  false 

assert  man-mvrs-in-head-preorder-mvrs-in-tail 
fa(m,  mvrl,  mvr2) 

mvrl  in  man-head(m)  &  mvr2  in  man-tail(m) 

=  >  man-mvr-less?(m,  mvrl,  mvr2) 

assert  man-mvrs-in-tail-do-not-preorder-mvrs-in-head 
fa(m,  mvrl,  mvr2) 

mvrl  in  man-head(m)  &  mvr2  in  man-tail(m) 

=  >  man-mvr-less?(m,  mvr2,  mvrl)  =  false 

assert  man-mark-loaded-refines-manifest 
fa(m,  mvr) 

mvr  in  man-unloaded(m) 

=  >  man-refined?  (m,  man-mark-mvr-loaded(m,  mvr)) 

assert  man-refinement-preserves-loaded-status 
fa(ml,  m2,  mvr) 

man-refined?(man-mark-mvr-loaded(ml,  mvr),  m2) 

=  >  man-mvr-has-been-loaded?(m2,  mvr) 

assert  man-mark-loaded-implies-has-been-loaded 
fa(m,  mvr) 

mvr  in  man-unloaded(m) 

=  >  man-mvr-bas-been-loaded?(man-mark-mvr-loaded(m,  mvr), 

mvr) 


END-THEORY 

A.5  Geometry 


!!  in-paekage("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'eypress-grammar) 
%  Represents  tbe  geometry  of  a  yard. 

THEORY  GEOMETRY 


% - 

THEORY-IMPORTS  {SLOT,  TIME-AND-DISTANCE} 
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% - 

THEORY-TYPES 

type  geo  =  tuple(distanees:  seq(seq(distanee)), 
eount;  fixnum) 


% - 

THEORY-OPERATIONS 
funetion  geo-make-emptyO:  geo 

=  <[],o> 

funetion  geo-next-number(g;  geo):  integer 
=  g. eount  +  1 

funetion  geo-add-slot(g;  geo,  name:  slot-name):  tuple(geo,  slot) 

=  let(new-dists:  seq(seq(distanee)) 

=  append(image(lambda(s)  append(s,  *undefined*),  g.distanees), 
[  *undefmed*  |  (i)  i  in  [1  ..  geo-next-number(g)]])) 

<  <new-dists,  geo-next-number(g)  > , 

sl-make(geo-next-number(g),  name)  > 

funetion  geo-add-assymetrie-separation(g:  geo, 
sre:  slot-id,  des:  slot-id,  dist:  distanee 
):  geo 

=  let(new-dist:  seq(seq(distanee))  = 
seq-shadowl (g.distanees,  sre, 

seq-shadowl(g.distanees(sre),  des,  dist))) 

<new-dist,  g. eount > 

funetion  geo-add-separation(g:  geo, 
sre:  slot-id,  des:  slot-id,  dist:  distanee 
):  geo 

=  geo-add-assymetrie-separation( 
geo-add-assymetrie-separation(g,  sre,  des,  dist), 
des,  sre,  dist) 

funetion  geo-slot-ids(g:  geo):  set( slot-id) 

=  {1  ..  g. eount} 

funetion  geo-distanee(g:  geo,  sre:  slot-id,  des:  slot-id 
I  sre  in  geo-slot-ids(g) 

&  des  in  geo-slot-ids(g) 

):  distanee 

=  g.distanees(sre)(des) 
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END-THEORY 


A.6  Hostler 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 
%  Represents  a  hostler. 

THEORY  HOSTLER 


% - 

THEORY-IMPORTS  {TIME-AND-DISTANCE,  SLOT,  CARGO, 
GEOMETRY,  MOVEMENT-REQUEST} 


% - 

THEORY-TYPES 

type  hostler-id  =  fixnum 
type  hostler-name  =  symbol 

type  hostler  =  tuple(id;  hostler-id,  name:  hostler-name) 


% - 

THEORY-OPERATIONS 

funetion  hos-make(id;  hostler-id,  name:  hostler-name):  hostler 
=  <  id,  name  > 

funetion  hos-id(h:  hostler):  hostler-id 
=  h.id 

funetion  hos-speed(h:  hostler,  e:  eargo):  speed 
=  *LOADED-HOSTLER-SPEED* 

funetion  hos-unloaded-speed(h:  hostler):  speed 
=  *UNLOADED-HOSTLER-SPEED* 

funetion  hos-duration-for-move(h:  hostler,  mvr:  mvr,  g:  geo):  duration 
=  add-durations( 

mvr-distanee(mvr,  g) 
div  hos-speed(h,  mvr-eargo(mvr)). 
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*TRIP-DURATION-OVERHEAD*) 


function  hos-duration-for-unloaded-trip(h:  hostler, 
src:  slot-id,  des:  slot-id,  g:  geo) 

:  duration 

=  geo-distanee(g,  sre,  des) 
div  hos-unloaded-speed(h) 

funetion  hos-duration-for-repositioning(h:  hostler, 
mvrl:  mvr,  mvr2:  mvr,  g:  geo) 

;  duration 
=  add-durations( 

hos-duration-for-unloaded-trip(h, 
mvr-destination(mvrl),  mvr-souree(mvr2),  g), 
*REPOSITIONING-OVERHEAD*) 

funetion  hos-duration-for-move-with-repositioning(h;  hostler, 
mvr:  mvr,  origin;  slot-id,  g:  geo 
):  duration 
=  add-durations( 

add-durations( 

hos-duration-for-move(h,  mvr,  g), 
hos-duration-for-unloaded-trip(h,  origin,  mvr-souree(mvr),  g)), 
*REPOSITIONING-OVERHEAD*) 

END-THEORY 


A.7  Yard 


!!  in-paekage("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'eypress-grammar) 
%  Represents  a  eargo  yard;  geometry,  resourees. 

THEORY  YARD 


% - 

THEORY-IMPORTS  {SLOT,  HOSTLER,  GEOMETRY} 

%  - 

THEORY-TYPES 
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type  yard  =  tuple( 
slots:  map(slot-id,  slot), 
hostlers:  map(hostler-id,  hostler), 
geometry:  geo, 
eaehed-hostlers:  set(hostler), 
number-of-hostlers:  fixnum 
) 


% - 

THEORY-OPERATIONS 

funetion  y-make(S:  set(slot),  H:  set(hostler),  G:  geo):  yard 
=  <  { I  sl-id(sl)  -  >  si  I  (si:  slot)  si  in  S  | }, 

{ I  hos-id(ho)  ->  ho  I  (ho:  hostler)  ho  in  H  | }, 

G, 

H, 

size(H) 

> 

funetion  y-slot-ids(y:  yard):  set(slot-id) 

=  domain(y.  slots) 

funetion  y-slot(y:  yard,  s-id:  slot-id 

I  s-id  in  y-slot-ids(y) 

):  slot 

=  y.slots(s-id) 

funetion  y-slot-from-name(y:  yard,  name:  slot-name):  slot 
=  arb(filter(lambda(s:  slot)  sl-name(s)  =  name,  range(y. slots))) 

funetion  y-hostler-ids(y:  yard):  set(hostler-id) 

=  domain(y.  hostlers) 

funetion  y-hostler(y:  yard,  h-id:  hostler-id 
I  h-id  in  y-hostler-ids(y) 

):  hostler 
=  y.hostlers(h-id) 

funetion  y-hostlers(y:  yard):  set(hostler) 

=  y.  eaehed-hostlers 

funetion  y-geometry(y:  yard):  geo 
=  y.  geometry 

funetion  y-number-of-hostlers(Y:  yard):  fixnum 
=  y.  number-of-hostlers 
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END-THEORY 


A.8  Reservation 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 

%  Represents  a  reservation  of  a  hostler  for  a  eargo  item 
%  in  a  sehedule. 

THEORY  RESERVATION 


% - 

THEORY-IMPORTS  (HOSTLER,  MOVEMENT-REQUEST,  TIME-AND-DISTANCE, 
YARD} 

%  - 

THEORY-TYPES 

type  rvn  =  tuple(hoslter-id;  hostler-id, 
mvr:  mvr, 

period;  period) 


% - 

THEORY-OPERATIONS 

funetion  rvn-make(h:  hostler-id,  mvr;  mvr,  p;  period,  Y;  yard);  rvn 
=  <  h,  mvr,  p  > 

funetion  rvn-hostler-id(r;  rvn);  hostler-id 
=  r.hoslter-id 

funetion  rvn-mvr(r;  rvn);  mvr 
=  r.mvr 

funetion  rvn-period(r;  rvn);  period 
=  r.  period 

END-THEORY 
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A.9  Schedule 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 
THEORY  SCHEDULE 


% - 

THEORY-IMPORTS  {TIME-AND-DISTANCE,  HOSTLER,  MOVEMENT-REQUEST, 
RESERVATION,  GEOMETRY,  YARD,  SHIP-MANIEEST} 


% 


THEORY-TYPE-PARAMETERS  {} 


% 


THEORY-TYPES 
type  h-info  =  tuple(rvns;  seq(rvn), 
load;  duration, 
elosure-time:  time, 
elosure-slot:  slot-id) 

type  sehedule  =  tuple(hostlers:  seq(h-info), 
eaehed-h-ids;  set(hostler-id), 
elosure:  rvn, 

sum-of-elosure-times:  time) 


% - 

THEORY-OPERATIONS 
funetion  seh-make-empty(n:  fixnum):  sehedule 
=  <[<[],  0,  0,  undefined >  |  (i)  i  in  [1  ..  n]], 
{}, 

undefined, 

0 

> 

funetion  seh-is-empty?(S:  sehedule):  boolean 
=  not(defined?(S. elosure)) 

funetion  seh-hostler-ids(S:  sehedule):  set(hostler-id) 
=  S.  eaehed-h-ids 
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function  sch-size(S:  schedule):  fixnum 
=  reduee(  +  , 

image(lambda(h-id)  size(S .  hostler s(h-id) .  rvns) , 
seh-hostler-ids(S)) , 


0) 


funetion  seh-sort-reservations(rs:  set(rvn)):  seq(rvn) 

=  sort(rs,  lambda(rl:  rvn,  r2:  rvn)  is-earlier-time?( 
pd-start(rvn-period(r  1 )) , 
pd-start(rvn-period(r2)))) 

funetion  seh-reservations-for-hostler(S:  sehedule,  h-id:  hostler-id) 
:  set(rvn) 

=  seq-to-set(S .  hostler  s(h-id) .  rvns) 

funetion  seh-ordered-reservations-for-hostler(S:  sehedule, 

h-id;  hostler-id) 

;  seq(rvn) 

=  S .  hostler  s(h-id) .  rvns 


funetion  find-preeeeding-reservation-aux( 
rvns:  seq(rvn),  ti:  time,  1:  fixnum,  u:  fixnum 
):  rvn 
=  ifl=u 

then  if  1<  =size(rvns)  then  rvns(l)  else  undefined 
else 

let(m:  fixnum  =  (1-l-u)  div  2) 
if  is-earlier-time?(pd-end(rvn-period(rvns(m))),  ti) 
then  find-preeeeding-reservation-aux(rvns,  ti,  m,  u) 
else  find-preeeeding-reservation-aux(rvns,  ti,  1,  m) 

funetion  find-preeeeding-reservation(rvns;  seq(rvn),  ti:  time):  rvn 
=  find-preeeeding-reservation-aux(rvns,  ti,  1,  size(rvns)) 

funetion  seh-all-reservations(S:  sehedule):  set(rvn) 

=  reduee(union,  [  seh-reservations-for-hostler(S,  h-id) 

I  (h-id;  hostler-id)  h-id  in  set-to-seq(seh-hostler-ids(S))]) 

funetion  seh-add-reservation(S;  sehedule,  r:  rvn):  sehedule 
=  let(h-id;  hostler-id  =  rvn-hostler-id(r)) 

let(new-rvns;  seq(rvn)  =  prepend(S.hostlers(h-id).rvns,  r), 
new-load;  duration  =  S.hostlers(h-id).load-l-pd-duration(rvn-period(r)), 
new-elosure-time:  time  =  pd-end(rvn-period(r)), 
new-elosure-slot:  slot-id  =  mvr-destination(rvn-mvr(r))) 
let(new-elosure;  rvn  = 
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if  not(defined?(S.  closure)) 
then  r 

else  if  new-closure-time  >pd-end(rvn-period(S. closure)) 
then  r 

else  S. closure, 

new-sum-of-closure-times:  time 
=  S.sum-of-closure-times 
-t-  new-closure-time 
-  S .  hostler s(h-id) .  closure-time) 

<seq-shadowl(S. hostlers,  h-id, 

<new-rvns,  new-load,  new-closure-time,  new-closure-slot>), 
S.cached-h-ids  with  h-id, 
new-closure, 

new-sum-of-closure-times  > 

function  sch-sum-of-closure-times(S:  schedule):  time 
=  S.sum-of-closure-times 

function  sch-closure-slot-for-hostler(S:  schedule,  h-id:  hostler-id) 

:  slot-id 

=  S .  hostler  s(h-id) .  closure-slot 

function  sch-extract-mvrs-from-seq-of-reservations(rs:  seq(rvn)) 

:  seq(mvr) 

=  image(lambda(r:rvn)  rvn-mvr(r),  rs) 

function  sch-last-reservation-for-hostler(S:  schedule,  h-id:  hostler-id) 
:  rvn 

=  first(S .  hostler  s(h-id) .  rvns) 

function  sch-closure-time-for-hostler(S:  schedule,  h-id:  hostler-id) 

:  time 

=  S .  hostler  s(h-id) .  closure-time 

function  sch-last-reservations(S:  schedule):  seq(rvn) 

=  [  sch-last-reservation-for-hostler(S,  h-id) 

I  (h-id:  hostler-id)  h-id  in  set-to-seq(sch-hostler-ids(S))  ] 

function  sch-closure-reservation(S:  schedule):  rvn 
=  S.  closure 

function  sch-closure-time(S:  schedule):  time 
=  let(r:  rvn  =  sch-closure-reservation(S)) 
if  defined?  (r) 

then  pd-end(rvn-period(r)) 
else  0 
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function  sch-rvns-are-successive(S:  schedule,  rl:  rvn,  r2:  rvn) 
:  boolean 

=  let(h-id;  hostler-id  =  rvn-hostler-id(rl)) 
h-id  =  rvn-hostler-id(r2) 
and  is-earlier-time?(pd-start(rvn-period(r  1 )) , 
pd-start(rvn-period(r2))) 
and  not(ex(r3:  rvn)( 

r3  in  seh-reservations-for-hostler(S,  h-id) 
and  is-earlier-time?(pd-start(rvn-period(r  1 )) , 
pd-start(rvn-period(r3))) 

and  is-earlier-time?(pd-start(rvn-period(r3)) , 
pd-start(rvn-period(r2))) 

)) 

funetion  seh-duration-for-hostler(S:  sehedule,  h-id;  hostler-id) 

:  duration 

=  S.hostlers(h-id).load 

funetion  seh-total-duration(S:  sehedule):  duration 
=  reduee(add-durations, 

[  seh-duration-for-hostler(S,  h-id) 

I  (h-id)  h-id  in  set-to-seq(seh-hostler-ids(S))] , 

0) 

END-THEORY 


A.  10  Work  Metric 


!!  in-paekage("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'eypress-grammar) 

%  Metries  on  sehedules,  based  on  "work  done" 

%  (i.e.,  eargo  shipped,  distanee  moved). 

%  Used  for  pruning  sehedules. 

THEORY  METRIC-WORK 


% - 

THEORY-IMPORTS  {HOSTLER,  MOVEMENT-REQUEST,  RESERVATION, 
GEOMETRY,  YARD,  SHIP-MANIEEST,  SCHEDULE,  TIME-AND-DISTANCE} 

%  - 
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THEORY-TYPES 
type  hsec  =  fixnum 


% - 

THEORY-OPERATIONS 

function  load-based-on-hostler(man;  manifest,  h:  hostler,  g;  geo):  hsec 
=  man-unloaded-distance(man) 

function  true-repositioning-cost-for-hostler( 

S:  schedule,  h-id;  hostler-id,  Y:  yard 
):  hsec 

=  let(ordered;  seq(rvn)  =  sch-ordered-reservations-for-hostler(S,  h-id)) 
let(h:  hostler  =  y-hostler(Y,  h-id)) 
reduce(  + , 

[  hos-duration-for-repositioning(h, 
rvn-mvr(ordered(i  -  1)),  rvn-mvr(ordered(i)),  y-geometry(Y)) 

I  (i:  integer)  i  in  [2  . .  size(ordered)]] , 

0) 

function  true-total-repositioning-cost(S:  schedule,  Y:  yard):  hsec 
=  reduce(+, 

[  true-repositioning -cost- for-hostler(S,  h-id,  Y) 

I  (h-id:  hostler-id)  h-id  in  set-to-seq(sch-hostler-ids(S))  ] , 

0) 

function  load-cost-for-hostler(S:  schedule,  h-id:  hostler-id):  hsec 
=  sch-duration-for-hostler(S,  h-id) 

function  total-load-cost(S:  schedule):  hsec 
=  sch-total-duration(S) 

function  work-cost- for-hostler(S:  schedule,  h-id:  hostler-id):  hsec 
=  sch-closure-time-for-hostler(S,  h-id) 

function  total-work-cost(S:  schedule):  hsec 
=  sch-sum-of-closure-times(S) 

function  total- work-cost-precompute(S:  schedule,  works:  seq(hsec)) 

:  hsec 
=  reduce(  +  , 

[  works(h-id) 

I  (h-id)  h-id  in  set-to-seq(sch-hostler-ids(S))]) 

function  work*(S:  schedule):  hsec 
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=  let(r:  rvn  =  sch-closure-reservation(S)) 
if  defined? (r) 

then  pd-end(rvn-period(r)) 
else  0 

funetion  work*-preeompute(S:  sehedule,  works:  seq(hsee)):  hsee 
=  reduee(lambda(x:  hsee,  y:  hsee) 
if  x>  =y  then  x  else  y, 

[  works(h-id) 

I  (h-id:  hostler-id)  h-id  in  set-to-seq(seh-hostler-ids(S))  ] , 

0) 

funetion  work*-id(S:  sehedule):  hostler-id 
=  arb({h-id  |  (h-id:  hostler-id)  h-id  in  seh-hostler-ids(S) 
and  work-eost-for-hostler(S,  h-id)  =  work*(S)}) 

funetion  repositioning-eost-for-hostler(S:  sehedule,  h-id:  hostler-id) 
:  hsee 

=  work-eost-for-hostler(S,  h-id)  -  load-eost-for-hostler(S,  h-id) 

funetion  total-repositioning-eost(S:  sehedule):  hsee 
=  total-work-eost(S)  -  total-load-eost(S) 

funetion  sehedule-eost(S:  sehedule,  Y:  yard):  hsee 
=  work*(S)  *  y-number-of-hostlers(Y) 

funetion  sehedule-eost-preeompute(S:  sehedule,  Y:  yard, 
works:  seq(hsee)):  hsee 

=  work*-preeompute(S,  works)  *  size(y-hostler-ids(y)) 

funetion  spare(S:  sehedule,  Y:  yard):  hsee 
=  sehedule-eost(S,  Y)  -  total- work-eost(S) 

funetion  find-shortest-distanees( 
d:  slot-id,  e:  integer,  ss:  seq(slot-id),  g:  geo 
):  seq(distanee) 

=  let(sorted:  seq(distanee) 

=  sort([geo-distanee(g,  d,  s)  |  (s)  s  in  ss], 
lambda(x,y)  x<  =y)) 

[sorted(i)  |  (i)  i  in  [1  ..  e]] 

funetion  find-shortest-distanees-for-souree( 
s:  slot-id,  e:  integer,  dd:  seq(slot-id),  g:  geo 
):  seq(distanee) 

=  let(sorted:  seq(distanee) 

=  sort([geo-distanee(g,  d,  s)  |  (d)  d  in  dd]. 
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lambda(x,y)  x<  =y)) 
[sorted(i)  |  (i)  i  in  [1  ..  c]] 


function  repo-lower-bound-from-destinations(S;  schedule, 

Y:  yard,  M:  manifest) 


:  hsee 

=  man-repositioning-lower-bound(M,  Y)  div  *UNLOADED-HOSTLER-SPEED* 
+  *REPOSITIONING-OVERHEAD* 


*  (size(man-unloaded(M))  -  y-number-of-hostlers(Y)) 


funetion  repo-lower-bound(S:  sehedule,  Y:  yard,  M:  manifest):  hsee 
=  let(d2  =  repo-lower-bound-from-destinations(S,  Y,  M)) 


d2 


funetion  find-largest-distanees( 
d;  slot-id,  e:  integer,  ss:  seq(slot-id),  g:  geo 
):  seq(distanee) 

=  let(sorted;  seq(distanee) 

=  sort([geo-distanee(g,  d,  s)  |  (s)  s  in  ss], 
lambda(x,y)  x>  =y)) 

[sorted(i)  |  (i)  i  in  [1  ..  e]] 

funetion  predieted-eost-pre-eompute-repo( 

S:  sehedule,  Y:  yard,  M:  manifest,  repo:  distanee,  load:  hsee 
):  hsee 

=  if  man-fmished?(M) 
then  sehedule-eost(S,  Y) 
else 

let(w:  hsee  =  total-work-eost(S), 
eost:  hsee  =  sehedule-eost(S,  Y)) 
let(spare-eost:  hsee  =  eost  -  w) 
if  load + repo  >  spare-eost 
then  eost  +  load  +  repo  -  spare-eost 
else  eost 


funetion  predieted-eost(S:  sehedule,  Y:  yard,  M:  manifest):  hsee 
=  predieted-eost-pre-eompute-repo(S,  Y,  M,  repo-lower-bound(S,  Y,  M), 
load-based-on-hostler(M , 
arb(y-hostlers(Y)) ,  y-geometry( Y))) 

funetion  lower-bound-for-delta-sehedule( 
old-S:  sehedule,  h-id:  hostler-id,  new-M:  manifest, 

Y:  yard,  repo:  distanee,  load:  hsee, 
rvn-h:  rvn 
):  hsee 

=  let(fts-h:  time  =  pd-end(rvn-period(rvn-h))) 
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let(new-closure-time;  time 
=  greater-i(sch-closure-time(old-S),  fts-h)) 

let(new-cost-S:  hsec  =  new-closure-time  *  y-number-of-hostlers(Y)) 
if  man-fmished?(new-M) 
then  new-cost-S 
else 

let(w:  hsec 

=  sch-sum-of-closure-times(old-S) 

-I-  fts-h  -  sch-closure-time-for-hostler(old-S,  h-id)) 

let(spare-cost:  hsec  =  new-cost-S  -  w) 

if  load -f  repo  >  spare-cost 

then  load  -I-  repo  -I-  w 

else  new-cost-S 

END-THEORY 


A.ll  VMS 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 
%  Defines  the  constraints  on  a  feasible  hostler  schedule. 
THEORY  YARD-MANAGEMENT-SYSTEM-2 


% - 

THEORY-IMPORTS  {HOSTLER,  MOVEMENT-REQUEST,  RESERVATION, 
GEOMETRY,  YARD,  SHIP-MANIEEST,  SCHEDULE} 

%  - 

THEORY-TYPE-PARAMETERS  {} 


%  - 

THEORY-TYPES 


%  - 

THEORY-OPERATIONS 

function  sch-sequence-of-mvr-refined?(sl:  seq(mvr),  s2:  seq(mvr)) 
:  boolean 
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=  size(sl)  <  =  size(s2) 

and-then  fa(i:  fixnum)(  i  in  domain(sl)  =  >  sl(i)  =  s2(i) ) 

function  schedule-refined? (SI:  sehedule,  S2:  sehedule):  boolean 
=  seh-hostler-ids(Sl)  subset  seh-hostler-ids(S2) 
and-then  fa(h-id;  hostler-id) 

(h-id  in  seh-hostler-ids(Sl) 

=  >  seh-sequenee-of-mvr-refined?( 
seh-extraet-mvrs-from-seq-of-reservations( 
seh-ordered-reservations-for-hostler(S  1 ,  h-id)), 
seh-extraet-mvrs-from-seq-of-reservations( 

seh-ordered-reservations-for-hostler(S2 ,  h-id))) 

) 

funetion  order-respeeted?(S:  sehedule,  man;  manifest):  boolean 
=  fa(rl:  rvn,  r2:  rvn) 

(rl  in  seh-all-reservations(S) 

and  r2  in  seh-all-reservations(S) 

=  >  man-mvr-less?(man,  rvn-mvr(rl),  rvn-mvr(r2)) 

=  >  is-earlier-time?(pd-end(rvn-period(rl)), 
pd-end(rvn-period(r2))) 

) 

funetion  feasible-resourees?(S:  sehedule,  Y:  yard):  boolean 
=  seh-hostler-ids(S)  subset  y-hostler-ids(Y) 

funetion  feasible-durations?(S:  sehedule,  Y:  yard):  boolean 
=  fa(r:  rvn)(r  in  seh-all-reservations(S) 

=  >  is-shorter-duration?( 
hos-duration-for-move( 

y-hostler(Y,  rvn-hostler-id(r)), 
rvn-mvr(r), 
y-geometry(Y)), 
pd-duration(rvn-period(r))) 

) 

funetion  feasible-separations?(S:  sehedule,  Y:  yard):  boolean 
=  fa(rl;  rvn,  r2:  rvn)( 

rl  in  seh-all-reservations(S) 
and  r2  in  seh-all-reservations(S) 
and  seh-rvns-are-sueeessive(S,  rl,  r2) 

=  >  is-later-time?( 
pd-start(rvn-period(r2)) , 
add-duration-to-time( 
pd-end(rvn-period(r  1 )) , 
hos-duration-for-repositioning( 
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y-hostler( Y ,  rvn-hostler-id(r  1 )) , 


rvn-mvr(rl), 

rvn-mvr(r2), 

y-geometry(Y)))) 

) 

function  YMS-Schedule(Y ;  yard,  man:  manifest  |  true) 
returns  (S:  schedule 
I  order-respected?(S,  man) 

&  feasible-durations?(S,  Y) 

&  feasible-separations?(S,  Y) 

&  feasible-resources?(S,  Y) 

) 

END-THEORY 


A.  12  Global  Search  with  Pruning 


!!  in-package("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'cypress-grammar) 
%  Theory  for  global  search  with  pruning. 

THEORY  SCHED-GS-PRUNING 


% - 

THEORY-IMPORTS  {HOSTLER,  MOVEMENT-REQUEST,  RESERVATION, 
GEOMETRY,  YARD,  SHIP-MANIEEST,  SCHEDULE, 
YARD-MANAGEMENT-SYSTEM-2,  SCHED-TESTER, 
SCHED-GREEDY-APPEND-EOR-EARLIEST-MVR-EINISH} 


% 


THEORY-TYPE-PARAMETERS  {} 


% 


THEORY-TYPES 
var  *tree-size*:  fixnum  =  0 
var  *leaf-size*:  fixnum  =  0 
var  *lb*:  hsec  =  999999 
var  *opt*:real  =  2.0 
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var  answer;  schedule  =  undefined 


% - 

THEORY-OPERATIONS 

function  fts(S;  schedule,  Y;  yard,  h-id;  hostler-id,  mvr:  mvr, 
lower-bound;  time,  mvr-duration;  duration) 

;  time 

=  let(close;time  = 
if  h-id  in  sch-hostler-ids(S) 
then  sch-closure-time-for-hostler(S,  h-id) 

-I-  mvr-duration 
-I-  geo-distance(y-geometry(Y), 
sch-closure-slot-for-hostler(S ,  h-id) , 
mvr-source(mvr)) 

div  *UNLOADED-HOSTLER-SPEED* 

+  *REPOSITIONING-OVERHEAD* 
else  add-duration-to-time(*EARLIEST-TIME*,  mvr-duration)) 
if  is-later-time?(lower-bound,  close) 
then  lower-bound 
else  close 

function  find-latest-reservation-of-lower-rank-aux( 
rvns;  seq(rvn),  man;  manifest,  m;  mvr,  1;  fixnum 
);  rvn 

=  if  1  >  size(rvns)  then  undefined 

elseif  man-mvr-less?(man,  rvn-mvr(rvns(l)),  m) 
then  rvns(l) 

else  fmd-latest-reservation-of-lower-rank-aux(rvns,  man, 

m,  1  +  1) 


function  find-latest-reservation-of-lower-rank( 
rvns;  seq(rvn),  man;  manifest,  m;  mvr 
);  rvn 

=  find-latest-reservation-of-lower-rank-aux(rvns,  man,  m,  1) 

function  find-latest-reservation-of-lower-rank-for-hostler( 

S;  schedule,  h-id;  hostler-id,  man;  manifest,  m;  mvr 
);  rvn 

=  let(rvns;  seq(rvn) 

=  sch-ordered-reservations-for-hostler(S,  h-id)) 
fmd-latest-reservation-of-lower-rank(rvns,  man,  m) 


function  find-latest-reservations-of-lower-rank( 
S;  schedule,  man;  manifest,  m;  mvr 
);  seq(rvn) 
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=  [  r  I  (r:  rvn,  h-id:  hostler-id) 

h-id  in  set-to-seq(sch-hostler-ids(S)) 

&  r  =  find-latest-reservation-of-lower-rank-for-hostler(S,  h-id,  man,  m) 

&  defined?  (r)  ] 

funetion  make-new-sehedule-for-hostler( 

S:  sehedule,  mvr:  mvr,  h-id;  hostler-id,  Y;  yard,  M:  manifest, 
earliest-end;  time,  mvr-duration;  duration 
):  sehedule 

=  let(fts-h  =  fts(S,  Y,  h-id,  mvr,  earliest-end,  mvr-duration)) 
let(rvn-h  =  rvn-make(h-id, 
mvr, 

pd-make-from-times( 
fts-h  -  mvr-duration, 
fts-h), 

Y)) 

let(new-S  =  seh-add-reservation(S,  rvn-h)) 
new-S 

funetion  gs-aux(S:  sehedule,  M:  manifest,  Y:  yard, 
opt-faetor:  real,  depth:  fixnum) 

:  sehedule 

=  *tree-size*  <-  *tree-size*  -I-  1; 
if  man-finished?(M) 
then  (*leaf-size*  <  -  *leaf-size*  -I-  1 ; 
if  sehedule-eost(S,  Y)  <  *lb* 
then  (*lb*  <-  sehedule-eost(S,  Y); 
print([*tree-size*,  *lb*]); 

S) 

else  undefined 

) 

else 

let(mvr-ehoiee:  mvr  =  arb(man-head(M))) 
let(manifests:  manifest 
=  man-mark-mvr-loaded(M,  mvr-ehoiee)) 

let(repos:  hsee  =  repo-lower-bound(S,  Y,  manifests)) 
let(pre-mvrs:  seq(rvn) 

=  find-latest-reservations-of-lower-rank(S,  M,  mvr-ehoiee)) 
let(earliest-end;  time  = 

max-seq-i(append([pd-end(rvn-period(pre-mvrs(i))) 

I  (i)  i  in  domain(pre-mvrs)] , 

*EARLIEST-TIME*))) 
let(mvr-duration:  duration 

=  mvr-distanee(mvr-ehoiee,  y-geometry(Y))  div  *LOADED-HOSTLER-SPEED* 
+  *TRIP-DURATION-OVERHEAD*) 
let(loads;  hsee 
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=  load-based-on-hostler(manifests,  arb(y-hostlers(Y)),  y-geometry(Y))) 
let(rvns:  map(hostler-id,  rvn) 

=  { I  h-id  -  >  r  I  (h-id:  hostler-id,  r:  rvn,  fts-h:  time) 
h-id  in  set-to-seq(y-hostler-ids(Y)) 

&  fts-h  =  fts(S,  Y,  h-id,  mvr-ehoiee,  earliest-end,  mvr-duration) 
&  r  =  rvn-make(h-id,  mvr-ehoiee, 
pd-make-from-times(fts-h  -  mvr-duration,  fts-h), 

Y)  |}) 

let(lower-bounds;  seq(tuple(mvr,  hostler-id,  hsee))  = 
sort([  <  mvr-ehoiee,  h-id,  lower-bound  > 

I  (h-id;  hostler-id,  lower-bound;  hsee, 
new-M;  manifest) 

h-id  in  set-to-seq(y-hostler-ids(Y)) 

&  h-id  <  =  depth 
&  new-M  =  manifests 
&  lower-bound  = 

lower-bound-for-delta-sehedule( 

S,  h-id,  new-M,  Y,  repos,  loads,  rvns(h-id)) 

], 

lambda(smel;  tuple(mvr,  hostler-id,  hsee), 
sme2;  tuple(mvr,  hostler-id,  hsee)) 
smel.3  <  =sme2.3)) 

let(sehedules;  seq(tuple(sehedule,  hsee))  = 

[<new-S,  eost> 

I  (sme;  tuple(mvr,  hostler-id,  hsee), 
h-id;  hostler-id,  lower-bound;  hsee, 
new-S;  sehedule,  eost;  hsee) 
sme  in  lower-bounds 

&  h-id  =  sme. 2  &  lower-bound  =  sme. 3 
&  new-S  =  (if  lower-bound  <  *lb*  *  opt-faetor 
then  gs-aux(seh-add-reservation(S,  rvns(h-id)), 
manifests,  Y,  opt-faetor,  depth +1) 

else  (*tree-size*  <-  *tree-size*  +  1; 
undefined)) 

&  defmed?(new-S) 

&  eost  =  if  defined?(new-S) 

then  sehedule-eost(new-S,  Y) 
else  undefined 

]) 

let(optimum;  tuple(sehedule,  hsee)  = 
if  not(empty(sehedules)) 
then  reduee(lambda(sml;  tuple(sehedule,  hsee), 
sm2;  tuple(sehedule,  hsee)) 
if  sml.2<  =sm2.2 
then  sml  else  sm2, 
sehedules) 


43 


else  <  undefined,  undefined  >) 
optimum.  1 

funetion  gs(M:  manifest,  Y;  yard,  opt:  real):  sehedule 
=  gs-aux(seh-make-empty(size(y-hostlers(Y))),  M,  Y, 
1.0/(1.0  +  opt/100.0),  1) 

funetion  test-sehedule(opts:  seq(real)) 

=  let(Y  =  eonstruet-yardO) 
let(M  =  eonstruet-manifest(Y)) 
let(initial:  sehedule 

=  greedy-append-for-earliest-mvr-finish(M,  Y)) 
let(lb  =  sehedule-eost(initial,  Y)) 
image(lambda(opt:  real) 

(*lb*  <-  lb; 

*tree-size*  <  -  0; 

*leaf-size*  <-0; 
answer  <-  gs(M,  Y,  opt); 

(if  defined?(answer) 
then  print([ 
lb, 

real-to-nearest-integer(opt),  *tree-size*,  *leaf-size*, 
sehedule-eost(answer,  Y), 
total-load-eost(answer) , 
true-total-repositioning-eost(answer ,  Y) , 
total-repositioning-eost(answer) 

-  true-total-repositioning-eost(answer,  Y), 
spare(answer,  Y)]) 

else  print([lb,  real-to-nearest-integer(opt), 
*tree-size*,  *leaf-size*,  undefined])); 
printC'"); 
undefined), 
opts) 

END-THEORY 


A.  13  Greedy  Heuristic  Scheduler 


!!  in-paekage("RE") 

!!  in-grammar('THEORY-GRAMMAR,  'eypress-grammar) 

%  Theory  for  greedy  heuristie  seheduler 
%  based  on  earliest  finishing  time. 
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THEORY  SCHED-GREEDY-APPEND-FOR-EARLIEST-MVR-FINISH 


THEORY-IMPORTS  {TIME-AND-DISTANCE,  CARGO,  SLOT,  GEOMETRY, 
MOVEMENT-REQUEST,  HOSTLER,  SHIP-MANIFEST,  YARD, 
RESERVATION,  SCHEDULE,  YARD-MANAGEMENT-SYSTEM-2,  SCHED- 
TESTER,  METRIC-WORK} 


% - 

THEORY-OPERATIONS 

function  separation-time(Y :  yard,  h-id;  hostler-id, 
mvrl:  mvr,  mvr2:  mvr) 

;  duration 

=  hos-duration-for-repositioning(y-hostler(Y,  h-id), 
mvrl,  mvr2,  y-geometry(Y)) 

function  duration-for-mvr(Y :  yard,  h-id;  hostler-id,  mvr:  mvr) 

;  duration 

=  hos-duration-for-move(y-hostler(Y,  h-id),  mvr,  y-geometry(Y)) 

function  duration-for-move-with-repositioning(Y :  yard,  h-id:  hostler-id, 
mvrl:  mvr,  mvr2:  mvr):  duration 
=  hos-duration-for-move-with-repositioning(y-hostler(Y,  h-id), 
mvr2,  mvr-destination(mvrl),  y-geometry(Y)) 

function  ftsl(S:  schedule,  Y:  yard,  h-id;  hostler-id,  mvr:  mvr, 
lower-bound:  time) 

;  time 

=  let(close:time  = 
if  h-id  in  sch-hostler-ids(S) 
then  add-duration-to-time( 
sch-closure-time-for-hostler(S ,  h-id) , 
duration-for-move-with-repositioning( 

Y,  h-id, 

rvn-mvr(sch-last-reservation-for-hostler(S ,  h-id)) , 
mvr)) 

else  add-duration-to-time( 

*EARLIEST-TIME*, 
duration- for-mvr(Y,  h-id,  mvr)) 

) 

if  is-later-time?(lower-bound,  close)  then  lower-bound  else  close 
function  greedy-append-for-earliest-mvr-finish-aux( 
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S:  schedule,  M:  manifest,  Y:  yard 
):  sehedule 

=  if  man-fmished?(M) 
then  S 
else 

let(mvr*:  mvr  =  arb(man-head(M))) 
let(pre:  set(rvn) 

=  seq-to-set(find-latest-reservations-of-lower-rank(S,  M,  mvr*))) 
let(earliest-end:  time 

=  max-i({pd-end(rvn-period(rvn))  |  (rvn:  rvn)  rvn  in  pre} 
with  *EARLIEST-TIME*)) 

let(fts*:  time  =  min-i({ftsl(S,  Y,  h-id,  mvr*,  earliest-end) 

I  (h-id: hostler-id)  h-id  in  y-hostler-ids(Y)})) 
let(h-id*:  hostler-id 

=  arb({h-id  |  (h-id;  hostler-id)  h-id  in  y-hostler-ids(Y) 
and  ftsl(S,  Y,  h-id,  mvr*,  earliest-end)  =  fts*})) 
let(rvn*:  rvn  =  rvn-make(h-id*, 

mvr*, 

pd-make-from-times( 
subtraet-duration-from-time(fts*, 
duration- for-mvr(Y,  h-id*,  mvr*)), 
fts*), 

Y)) 

let(new-S:  sehedule  =  seh-add-reservation(S,  rvn*), 
new-M:  manifest  =  man-mark-mvr-loaded(M,  mvr*)) 

greedy-append-for-earliest-mvr-finish-aux(new-S,  new-M,  Y) 
funetion  greedy-append-for-earliest-mvr-finish(M:  manifest,  Y:  yard) 
:  sehedule 

=  let  (empty-seh  =  seh-make-empty(size(y-hostlers(Y)))) 

greedy-append-for-earliest-mvr-finish-aux(empty-seh,  M,  Y) 

END-THEORY 
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